The background of the present disclosure is hereinafter introduced with the discussion of techniques relating to its context. However, even when this discussion refers to documents, acts, devices and the like, it does not suggest or represent that the discussed techniques are part of the prior art or are common general knowledge in the field relevant to the present disclosure.
Databases are commonly used to store large amount of data in structured form (for example, organized in tables in relational databases). Usually, before each client may access a generic database to perform any operations thereon (for example, to retrieve selected data), the client connects to the database by opening a corresponding connection. This involves the completion of all the arrangements that are required to allow the client to communicate with the database and to allow the database to process any operative command submitted thereto. Each connection is associated with a context that defines how the operative commands of the client are to be processed (for example, the identity of the client, assigned privileges and permissions).
The opening of any connection requires several operations that are relatively complex and time-consuming (for example, for authenticating the client); this may adversely affect the performance, especially when a few operative commands (down to a single one) are submitted to the database for each connection. Moreover, the connections waste a relatively high amount of resources (for example, memory space), even when they are inactive; therefore, most databases limit the maximum number of connections that may be open at the same time.
Often, the clients of the databases are software applications (referred to as application clients); in turn, each application client may be used by multiple users, such as physical persons (referred to as user clients) that access the database through the application client.
In this case, the application client may connect to the database on behalf of all its user clients; for this purpose, the application client always connects to the database with a corresponding context (i.e., its identity and highest possible privileges and permission), with the different privileges and permissions of the user clients that are then managed by the application client. In this way, it is also possible to exploit connection pooling techniques. For this purpose, a pool of connections (all with the same context of the application client) is created; whenever a connection is to be opened an available connection is instead retrieved from the pool and whenever a connection is to be closed it is instead returned to the pool (for example, by means of a connection wrapper that makes this behavior completely opaque to the application client). This allows reducing repeated openings and closings of the connections. However, the database is completely agnostic about the user clients actually accessing it.
Conversely, a connection to the database should be opened for each user client (with the corresponding context) to make the database aware of the user clients actually accessing it (for example, for security or logging purposes); however, this reduces the performance of the application client.
Alternatively, as described in U.S. Pat. No. 6,986,060 (the entire disclosure of which is herein incorporated by reference), a security context may be shared among different sessions on a database server. For this purpose, a function call may be used to record a context for an application client with the database server (for example, an application session between a user and an application). Another function call may then be used to associate the application client with a database session between the database server and the application. Whenever a request is receiver by the database server through the database session, the corresponding context is retrieved. A database operation required to satisfy the request is performed thereby enforcing access rights associated with this context (for example, by rewriting a query). This allows selectively switching a large number of application sessions among a smaller number of database sessions for connection pooling purposes.
Moreover, U.S. Pat. No. 8,549,038 as well (the entire disclosure of which is herein incorporated by reference) describes the sharing of a session; in this case, the session has a common context and a pluggable context that directly depends on the end user, the application and/or the privilege level.
However, the management of the different contexts at the level of the database requires a quite complex rewriting of the client applications; moreover, the sharing of the same connection by multiple application clients (with different contexts) may involve security exposures.
In addition, the article “Context transfer method through SQL for database security”, IPCOM000137107D, Publication Date: 8 Jun. 2006 (the entire disclosure of which is herein incorporated by reference) describes a technique for transferring context information to a database. For this purpose, a query is modified so as not to change its result; particularly, the context information is attached to the query as a predicate that is always true.